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Security Extension for OSPFv2 When Using Manual Key Management 
Abstract 


The current OSPFv2 cryptographic authentication mechanism as defined 
in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- 
session replay attacks when using manual keying. Additionally, the 
existing cryptographic authentication mechanism does not cover the IP 
header. This omission can be exploited to carry out various types of 
attacks. 


This document defines changes to the authentication sequence number 
mechanism that will protect OSPFv2 from both inter-session and intra- 
session replay attacks when using manual keys for securing OSPFv2 
protocol packets. Additionally, we also describe some changes in the 
cryptographic hash computation that will eliminate attacks resulting 
from OSPFv2 not protecting the IP header. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7474. 
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document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
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include Simplified BSD License text as described in Section 4.e of 
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Les 


Introduction 


The OSPFv2 cryptographic authentication mechanism as described in 
[RFC2328] uses per-packet sequence numbers to provide protection 
against replay attacks. The sequence numbers increase monotonically 
so that attempts to replay stale packets can be thwarted. The 
sequence number values are maintained as a part of neighbor adjacency 
state. Therefore, if an adjacency is taken down, the associated 
sequence numbers get reinitialized and neighbor adjacency formation 
starts over again. Additionally, the cryptographic authentication 
mechanism does not specify how to deal with the rollover of a 
sequence number when its value wraps. These omissions can be 
exploited by attackers to implement various replay attacks 
([RFC6039]). In order to address these issues, we define extensions 
to the authentication sequence number mechanism. 


The cryptographic authentication as described in [RFC2328] and later 
updated in [RFC5709] does not include the IP header. This omission 
can be exploited to launch several attacks as the source address in 
the IP header is not protected. The OSPF specification, for 
broadcast and NBMA (Non-Broadcast Multi-Access) networks, requires 
implementations to use the source address in the IP header to 
determine the neighbor from which the packet was received. Changing 
the IP source address of a packet to a conflicting IP address can be 
exploited to produce a number of denial-of-service attacks [RFC6039]. 
If the packet is interpreted as coming from a different neighbor, the 
received sequence number state for that neighbor may be incorrectly 
updated. This attack may disrupt communication with a legitimate 
neighbor. Hello packets may be reflected to cause a neighbor to 
appear to have one-way communication. Additionally, Database 
Description packets may be reflected in cases where the per-packet 
sequence numbers are sufficiently divergent in order to disrupt an 
adjacency [RFC6863]. This is the IP-layer issue described in point 
18 in Section 4 of [RFC6862]. 


[RFC2328] states that implementations MUST offer keyed MD5 
authentication. It is likely that this will be deprecated in favor 
of the stronger algorithms described in [RFC5709] and required in 
[RFC6094]. 


This document defines a few simple changes to the cryptographic 
authentication mechanism, as currently described in [RFC5709], to 
prevent such IP-layer attacks. 
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1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


When used in lowercase, these words convey their typical use in 
common language, and are not to be interpreted as described in RFC 
2119 [RFC2119]. 


2. Replay Protection Using Extended Sequence Numbers 


In order to provide replay protection against both inter-session and 
intra-session replay attacks, the OSPFv2 sequence number is expanded 
to 64 bits with the least significant 32-bit value containing a 
strictly increasing sequence number and the most significant 32-bit 
value containing the boot count. OSPFv2 implementations are required 
to retain the boot count in non-volatile storage for the deployment 
life of the OSPF router. The requirement to preserve the boot count 
is also placed on SNMP agents by the SNMPv3 security architecture 
(refer to snmpEngineBoots in Section 2.2 of [RFC3414]). 


Since there is no room in the OSPFv2 packet for a 64-bit sequence 
number, it will occupy the 8 octets following the OSPFv2 packet and 
MUST be included when calculating the OSPFv2 packet digest. These 
additional 8 octets are not included in the OSPFv2 packet header 
length but are included in the OSPFv2 header Authentication Data 
length and the IPv4 packet header length. 


The lower-order 32-bit sequence number MUST be incremented for every 
OSPF packet sent by the OSPF router. Upon reception, the sequence 
number MUST be greater than the sequence number in the last OSPF 
packet of that type accepted from the sending OSPF neighbor. 
Otherwise, the OSPF packet is considered a replayed packet and 
dropped. OSPF packets of different types may arrive out of order if 
they are prioritized as recommended in [RFC4222]. 


OSPF routers implementing this specification MUST use available 
mechanisms to preserve the sequence number’s strictly increasing 
property for the deployed life of the OSPFv2 router (including cold 


restarts). This is achieved by maintaining a boot count in non- 
volatile storage and incrementing it each time the OSPF router loses 
its prior sequence number state. The SNMPv3 snmpEngineBoots variable 


[RFC3414] MAY be used for this purpose. However, maintaining a 
separate boot count solely for OSPF sequence numbers has the 
advantage of decoupling SNMP reinitialization and OSPF 
reinitialization. Also, in the rare event that the lower-order 
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32-bit sequence number wraps, the boot count can be incremented to 
preserve the strictly increasing property of the aggregate sequence 
number. Hence, a separate OSPF boot count is RECOMMENDED. 


3. OSPF Packet Extensions 


The OSPF packet header includes an authentication type field, and 64 
bits of data for use by the appropriate authentication scheme 
(determined by the type field). Authentication types 0, 1, and 2 are 
defined [RFC2328]. This section defines Authentication type 3. 


When using this authentication scheme, the 64-bit Authentication 
field (as defined in Appendix D.3 of [RFC2328]) in the OSPF packet 
header (as defined in Appendix A.3.1 of [RFC2328] and [RFC6549]) is 
changed as shown in Figure 1. The sequence number is removed and the 
Key ID is extended to 32 bits and moved to the former position of the 
sequence number. 


Additionally, the 64-bit sequence number is moved to the first 64 
bits following the OSPFv2 packet and is protected by the 


authentication digest. These additional 64 bits or 8 octets are 
included in the IP header length but not the OSPF header packet 
length. 


Finally, the 0 field at the start of the OSPFv2 header authentication 
is extended from 16 bits to 24 bits. 
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4. 


0 Í 2 3 
0123456789012345678°9012345678<90 21 
$otatatotitatitotatititatitotatitotatatotatitotatattitit-t-t-t- 
| Version # | Type | Packet length 
+ototat-t-tat-t-tatatitatititatitotatitotatititatitit-tit-t-t-t- 
| Router ID 
fotatat-t-tat-totatotatatitotataitotatitotatitotatatititit-t-t-t- 
| Area ID 
$ot-tat-t-tat-t-tatotitatitotatitotatitotatitotatatit-tat-t-t-t- 
| Checksum | Instance ID | AuType 
+-+-+-+-+-+-+-+-+-+-+-+- ++ 
| 0 | Auth Data Len 
+-+-+-+-+-+-+-+-+-+-+-+- +t 
| Key ID 
+-+-+-+-+-+-+-+-+-+-+-+- ++ 


OSPF Protocol Packet 


a 


—+-—4-4+-4+-+4-+4+-4-4-4-+4+-4+-4+-+-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4- 
Sequence Number (Boot Count) 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Sequence Number (Strictly Increasing Packet Counter) 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


:— + — + — + — 


Authentication Data 


t—+—-+-4+-+4+-4+-4-4+-4+-4-4+-4+-4+-4-4+-4+-4-4-4+-4t-4+-4-4t-4-4-4+-4+-4-4-4+-4-4- 
Figure 1: Extended Sequence Number Packet Extensions 
OSPF Packet Key Selection 


This section describes how this security solution selects long-lived 
keys from key tables. [RFC7210]. In this context, we are selecting 
the key and corresponding Security Association (SA) as defined in 
Section 3.2 of [RFC5709]. Generally, a key used for OSPFv2 packet 
authentication should satisfy the following requirements: 


o For packet transmission, the key validity interval as defined by 
SendLifetimeStart and SendLifetimeEnd must include the current 
time. 


o For packet reception, the key validity interval as defined by 
AcceptLifetimeStart and AcceptLifetimeEnd must include the curren 
time. 
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o The key must be valid for the desired security algorithm. 


In the remainder of this section, additional requirements for keys 
are enumerated for different scenarios. 


4.1. Key Selection for Unicast OSPF Packet Transmission 


Assume that a router R1 tries to send a unicast OSPF packet from its 
interface Il to the interface I2 of a remote router R2 using security 
protocol P via interface I at time T. First, consider the 
circumstances where R1 and R2 are not connected with a virtual link. 
R1 then needs to select a long-lived symmetric key from its key 
table. Because the key should be shared by both R1 and R2 to protect 
the communication between I1 and 12, the key should satisfy the 
following requirements: 


o The Peers field contains the area ID or, if no key containing the 
area ID is present, the string "all". 


o The Direction field is either "out" or "both". 
o The Interfaces field matches I1 or "all". 


o If multiple keys match the Interface field, keys that explicitly 
match I1 should be preferred over keys matching "all". If there 
are still multiple keys that match, the key with the most recent 
SendLifetimeStart will be selected. This will facilitate graceful 
key rollover. 


o The Key ID field in the OSPFv2 header (refer to Figure 1) will be 
set to the selected key’s LocalKeyName. 


When R1 and R2 are connected to a virtual link, the Peers field must 
identify the virtual endpoint rather than the virtual link. Since 
there may be virtual links to the same router, the transit area ID 
must be part of the identifier. Hence, the key should satisfy the 
following requirements: 


o The Peers field includes both the virtual endpoint’s OSPF router 
ID and the transit area ID for the virtual link in the form of the 
transit area ID, followed by a colon, followed by the router ID. 
If no such key exists, then a key with the Peers field set to the 
transit area ID is used, followed by a key with the Peers field 
set to "all". 


o The Interfaces field is not used for key selection on virtual 
links. 
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(0) 


The Direction field is either "out" or "both". 


If multiple keys match the Peers field, keys that explicitly match 
the router ID should be preferred, followed by keys with a transit 
area specified, followed by keys with the Peers field set to 
"all". If there are still multiple keys that match, the key with 
the most recent SendLifetimeStart will be selected. This will 
facilitate graceful key rollover. 


The Key ID field in the OSPFv2 header (refer to Figure 1) will be 
set to the selected key’s LocalKeyName. 


Key Selection for Multicast OSPF Packet Transmission 


If a router R1 sends an OSPF packet from its interface Il toa 
multicast address (i.e., Al1SPFRouters or AllDRouters), it needs to 
select a key according to the following requirements: 


(0) 


First, try a key with the Peers field containing the area ID to 
which the interface belongs. If no key exists, try a key with the 
Peers field "all". 


The Interfaces field matches the interface over which the packet 
is sent or "all". 


The Direction field is either "out" or "both". 


If multiple keys match the Interface field, keys that explicitly 
match I1 should be preferred over keys matching "all". If there 
are still multiple keys that match, the key with the most resent 
SendLifetimeStart will be selected. This will facilitate graceful 
key rollover. 


The Key ID field in the OSPFv2 header (refer to Figure 1) will be 
set to the selected key’s LocalKeyName. 


Key Selection for OSPF Packet Reception 


When cryptographic authentication is used, the ID of the 
authentication key is included in the authentication field of the 
OSPF packet header. Using this Key ID, it is straight forward for a 
receiver to locate the corresponding key. The simple requirements 
are: 


(0) 


The interface on which the key was received is associated with the 
key’s interface. 
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o The Key ID obtained from the OSPFv2 packet header corresponds to 
the neighbor’s PeerKeyName. Since OSPFv2 keys are symmetric, the 
LocalKeyName and PeerKeyName for OSPFv2 keys will be identical. 
Hence, the Key ID will be used to select the correct local key. 


o The Direction field is either "in" or "both". 


o The Peers field matches as described in Sections Section 4.1 and 
Section 4.2. 


5. Securing the IP Header 


This document updates the definition of the Apad constant, as it is 
defined in [RFC5709], to include the IP source address from the IP 
header of the OSPFv2 protocol packet. The overall cryptographic 
authentication process defined in [RFC5709] remains unchanged. To 
reduce the potential for confusion, this section minimizes the 
repetition of text from RFC 5709 [RFC5709]. The changes are: 


RFC 5709, Section 3.3 describes how the cryptographic authentication 
must be computed. In RFC 5709, the First-Hash includes the OSPF 
packet and Authentication Trailer. With this specification, the 
64-bit sequence number will be included in the First-Hash along with 
the Authentication Trailer and OSPF packet. 


RFC 5709, Section 3.3 also requires the OSPFv2 packet’s 
Authentication Trailer (which is the appendage described in RFC 2328, 
Appendix D.4.3, page 233, items (6) (a) and (6) (d)) to be filled with 
the value Apad. Apad is a hexadecimal constant with the value 
Ox878FE1F3 repeated (L/4) times, where L is the length of the hash 
being used and is measured in octets rather than bits. 


OSPF routers sending OSPF packets must initialize the first 4 octets 
of Apad to the value of the IP source address that would be used when 
sending the OSPFv2 packet. The remainder of Apad will contain the 
value O0x878FE1F3 repeated (L - 4)/4 times, where L is the length of 
the hash, measured in octets. The basic idea is to incorporate the 
IP source address from the IP header in the cryptographic 
authentication computation so that any change of IP source address in 
a replayed packet can be detected. 


When an OSPF packet is received, implementations MUST initialize the 
first 4 octets of Apad to the IP source address from the IP header of 
the incoming OSPFv2 packet. The remainder of Apad will contain the 
value 0x878FE1F3 repeated (L - 4)/4 times, where L is the length of 
the hash, measured in octets. Besides changing the value of Apad, 
this document does not introduce any other changes to the 
authentication mechanism described in [RFC5709]. This would prevent 
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all attacks where a rogue OSPF router changes the IP source address 
of an OSPFv2 packet and replays it on the same multi-access interface 
or another interface since the IP source address is now included in 
the cryptographic hash computation and modification would result in 
the OSPFv2 packet being dropped due to an authentication failure. 


6. Mitigating Cross-—Protocol Attacks 


In order to prevent cross-protocol replay attacks for protocols 
sharing common keys, the two-octet OSPFv2 Cryptographic Protocol ID 
is appended to the authentication key prior to use. Refer to the 
IANA Considerations (Section 9). 


[RFC5709], Section 3.3 describes the mechanism to prepare the key 
used in the hash computation. This document updates the text under 
"(1) PREPARATION OF KEY" as follows: 


The OSPFv2 Cryptographic Protocol ID is appended to the 
Authentication Key (K) yielding a Protocol-Specific Authentication 
Key (Ks). In this application, Ko is always L octets long. While 
[RFC2104] supports a key that is up to B octets long, this 
application uses L as the Ks length consistent with [RFC4822], 
[RFC5310], and [RFC5709]. According to [FIPS-198], Section 3, 
keys greater than L octets do not significantly increase the 
function strength. Ks is computed as follows: 


If the Protocol-Specific Authentication Key (Ks) is L octets long, 
then Ko is equal to Ks. If the Protocol-Specific Authentication 
Key (Ks) is more than L octets long, then Ko is set to H(Ks). If 
the Protocol-Specific Authentication Key (Ks) is less than L 
octets long, then Ko is set to the Protocol-Specific 
Authentication Key (Ks) with zeros appended to the end of the 
Protocol-Specific Authentication Key (Ks) such that Ko is L octets 
long. 


Once the cryptographic key (Ko) used with the hash algorithm is 
derived, the rest of the authentication mechanism described in 
[RFC5709] remains unchanged other than one detail that was 
unspecified. When XORing Ko and Ipad of Opad, Ko MUST be padded with 
zeros to the length of Ipad or Opad. It is expected that 
implementations of [RFC5709] perform this padding implicitly. 
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7. 


Backward Compatibility 


This security extension uses a new authentication type, AuType in the 
OSPFv2 header (refer to Figure 1). When an OSPFv2 packet is received 
and the AuType doesn’t match the configured authentication type for 
the interface, the OSPFv2 packet will be dropped as specified in RFC 
2328 [RFC2328]. This guarantees backward-compatible behavior 
consistent with any other authentication type mismatch. 


Security Considerations 


This document rectifies the manual key management procedure that 
currently exists within OSPFv2, as part of Phase 1 of the KARP 
Working Group. Therefore, only the OSPFv2 manual key management 
mechanism is considered. Any solution that takes advantage of the 
automatic key management mechanism is beyond the scope of this 
document. 


The described sequence number extension offers most of the benefits 
of more complicated mechanisms without their attendant challenges. 
There are, however, a couple drawbacks to this approach. First, it 
requires the OSPF implementation to be able to save its boot count in 
non-volatile storage. If the non-volatile storage is ever repaired 
or upgraded such that the contents are lost or the OSPFv2 router is 
replaced, the authentication keys MUST be changed to prevent replay 
attacks. 


Second, if a router is taken out of service completely (either 
intentionally or due to a persistent failure), the potential exists 
for reestablishment of an OSPFv2 adjacency by replaying the entire 
OSPFv2 session establishment. However, this scenario is extremely 
unlikely, since it would imply an identical OSPFv2 adjacency 
formation packet exchange. Without adjacency formation, the replay 
of OSPFv2 hello packets alone for an OSPFv2 router that has been 
taken out of service should not result in any serious attack, as the 
only consequence is superfluous processing. Of course, this attack 
could also be thwarted by changing the relevant manual keys. 


This document also provides a solution to prevent certain denial-of- 
service attacks that can be launched by changing the source address 
in the IP header of an OSPFv2 protocol packet. 


Using a single crypto sequence number can leave the router vulnerable 
to a replay attack where it uses the same source IP address on two 
different point-to-point unnumbered links. In such environments 
where an attacker can actively tap the point-to-point links, it’s 
recommended that the user employ different keys on each of those 
unnumbered IP interfaces. 
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9. IANA Considerations 


This document registers a new code point from the "OSPF Shortest Path 
First (OSPF) Authentication Codes" registry: 


o 3 - Cryptographic Authentication with Extended Sequence Numbers. 


This document also registers a new code point from the 
"Authentication Cryptographic Protocol ID" registry defined under 
"Keying and Authentication for Routing Protocols (KARP) Parameters": 


o 3 - OSPFv2. 
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